The Secure Sockets Layer (SSL) protocol, a network communication protocol originally defined by Netscape Communications Corporation, and improvements such as TLS, provide ways for a client to communicate with a server in a confidential or secure manner over a public network. In basic terms, SSL involves negotiating an encryption method between the client and server, and then encrypting data that is subsequently communicated among the client and server using the negotiated encryption method. In this context, “client” refers to an end station device that receives network services, such as a workstation, personal computer, personal digital assistant, etc., and “server” refers to a processing device that provides network services to one or more clients, such as a server-class computer, mini-computer, mainframe, etc. The client and server may be peers.
SSL communications among a client and server happen in two distinct phases called a “handshake phase” and a “data phase.” An alert phase is also defined for identifying and reporting certain errors that occur in the other phases. In the handshake phase, the client and server communicate information that negotiates agreed-upon security parameter values. In basic terms, the handshake phase is carried out because the client and server initially do not know or trust one another and therefore must negotiate a way to encrypt communications among them. In the data phase, the client or server (a “party”) encrypts information using the agreed-upon security parameter values and sends it to the opposite party, which decrypts it using the security parameters.
The handshake phase requires the client and server to exchange numerous messages. Further, the handshake process requires the server to carry out a CPU-intensive, time-consuming computation of decrypting a message using private key values, and other encryption parameters using relative complex mathematical calculations. As a result, the handshake phase is time-consuming and intensive in terms of use of processor resources. Therefore, it is desirable to minimize the number of times that the time-consuming and CPU-intensive operations are carried out among a particular client and server.
However, information that is encrypted using SSL is commonly carried over a network using connection-oriented transport protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Under these protocols, and others, communications among a client and server are carried out using a succession of separate connections to request and receive portions of a message or transaction. For example, when a client requests a Web page from a server that contains one text portion and three embedded images, obtaining the complete Web page might require establishing four TCP/IP connections, communicating the text portion and images under the connections, and terminating the connections. If the Web page is requested using SSL, the client and server may have to carry out the SSL handshake phase repeatedly. Thus, there is a need for a way to establish SSL connections while avoiding time-consuming and CPU-intensive aspects of SSL connection negotiation.
To reduce time and processing overhead involved in repeated negotiation of security parameters in the handshake phase, SSL defines a “session resumption” process. During the handshake phase, the server generates a unique session identifier value (Session ID) and provides the Session ID to the client. Both the client and the server store a mapping between the Session ID and the security parameters agreed upon for a particular Session ID. Thereafter, to establish a separate SSL connection, the client requests the server to set up the connection and provides the Session ID in the request. Since the server has a mapping of the Session ID to the security parameters, the Session ID implicitly informs the server about what security parameters the client is expecting the server to use. The server can encrypt its communications to the client using such security parameters, without negotiating new security parameters, and the client can decrypt the communications. This substantially reduces time and processing resources needed to carry out the handshake phase.
The performance of server systems that use SSL extensively is improved by implementing SSL processing functions in a server element called an SSL termination engine that serves as a SSL proxy. The server system has a plurality of processors that carry out substantive application functions for clients. The SSL termination engines can compute encryption keys, encrypt outgoing data traffic, and decrypt incoming data traffic for a plurality of the processors.
Generally, each of the processors is responsible for responding to a subset of all clients, or for a specified set of sessions. Each of the processors has access to its own session table or other data store in which it stores a mapping of the Session ID values to security parameters that have been negotiated for sessions. When inbound data traffic arrives at a processor, it maps the Session ID in the traffic to the correct security parameters and processes the traffic using such parameters.
Such a system can be further enhanced or “scaled” by providing a plurality of SSL termination engines that are managed by a load-balancing device. In one embodiment, the load-balancing device is in the SSL proxy; alternatively, it may be separate. Client requests all arrive at the load-balancing device. The load-balancing device selects one of the SSL termination engines to handle the request, based on information about the then-current processing load of the SSL termination engines. The client request is passed to the selected SSL termination engine, and processing occurs in the manner described above.
A drawback of this approach is that a session security mapping of a particular processor may lack the required security parameter values for a particular session when traffic for that session is routed to the processor by the load-balancing device. For example, assume that a system can process up to 1024 concurrent SSL sessions. Each SSL Termination Engine may have one or more processors. Assume further that SSL Termination Engine 0 is associated with Processor 0 among a plurality of processors, which is responsible for processing application requests for Session ID values of “0” to “127.” Further assume that a client sends the system a request that asks to use SSL session resumption, and provides SSL Session ID “255.” However, the load-balancing device determines that SSL Termination Engine 0 has the lightest then-current processing load and should process the request. SSL Termination Engine 0 then forwards the request to Processor 0, but values for Session ID “255” are not in the mapping of Processor 0.
In this situation, Processor 0 is obligated to initiate negotiation of SSL security parameters with the client in the handshake phase, even though the correct security parameters probably are located in a mapping of a different processor. As a result, processing delays occur and processing resources are used unnecessarily. Further, the specific benefits of SSL session resumption are not achieved.
Based on the foregoing, there is a clear need for a way to extend the benefits of SSL session resumption to a system that includes a plurality of load-balanced SSL termination engines and associated processors.
There is a specific need for a way to route successive client requests to a processor that already holds SSL security parameter information for the associated client, so that the client and processor can use SSL session resumption.